To request data, a query needs to be designed and sent to the back end. The query can also contain information about the parameters that are to be sent with the request, their references, data types and so on. This implementation is required for all applications that expose Web service operations in Process Platform. The implementation part contains the application specific implementation of the Web service operation. For example, for an OLEDB connector, the implementation would be a SQL statement. The implementation is stored as thebusmethodimplementationparameter of the LDAP Web service operation and has the following structure:

<implementation type="...">
    <constructor language="...">
        <query>...</query>
        <parameters> ... </parameters>
    </constructor>
</implementation>

In the above structure:

• type- contains the type of the implementation in the bus Web service operation.
  
• language- contains the language of the query. In most cases, the implementation type is equal to the constructor language.
  
• query- contains the definition of the query that is to be sent to the back end.
  
• parameterscontains the list of fields or parameters that can be passed with the request.
  The parameter defined in an implementation is of the following structure:

  <parameters>
      <parameterName dd="..." dt="..."/> ... ... </parameters>
  

  
  In the above structure:
  
  
• parameterNamecontains the name of the parameter for the request.
  
• ddcontains the definition of the parameter. This denotes the actual field in the table.
  
• dtcontains the data type of the parameter.
  Associated queries (queries in which the primary table is associated to the related tables, and a series of inner connections are established between them) are represented in the implementation as shown in the following structure:

  <implementation type="...">
      <constructor language="...">
          <query>...</query>
          <parameters/>
          <constructor id="..." language="...">
              <query>...</query>
              <parameters/>
          </constructor>
          <layout> ... </layout>
      </constructor>
  </implementation>
  

  As shown in the above structure, a constructor is represented inside an outer constructor for associated queries. Since queries are inner connections, each constructor will contain a set of queries and parameters. All the inner constructors contain an attribute id that is used to identify each inner query uniquely. Additionally, a layout is defined inside each constructor, which contains the information about the business objects and the inner objects involved. The structure of a layout is as follows:

  <layout>
      <outer-table>
          <inner-table href="#id" relation="association" type="constructor"/> ... ... </outer-table>
  </layout>
  

  
  In the above structure:
  
  
• outer-table- contains the name of the business object for which the constructor is defined.
  
• inner-table- contains the name of the inner business object.
  
• href- contains the reference ID of the business object. This ID is a '#' followed by the ID of the constructor.
  
• relation- contains the type of the relation involved between the business objects. This will be 'association' for Associated queries.